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place of the interface or interface service requested by 
the program. 

[001 1] instead of identifying an implementation class 
or instance of an implementation, the registry may iden- 
tify a class loader associated with an Implementation of 
the interface or information from which such a class 
loader may be generated. In this case, the class loader 
is instantiated (unless, perhaps, an instance of the dass 
loader is already available), and the implementation is 
then instantiated. A reference to the newly created im- 
plementation instance is then retumed-to the program 
or the implementation may be invoked In place of the 
interface or interface service requested by the program. 
[0012] However, the registry may not identify an inrv 
plementation of the interface, an associated class load- 
er or means for creating one or the other In this event 
a locator attempts to locate such Infomnation so that, for 
example, the system can create a class loader that can 
instantiate an implementation of the interface. The loca- 
tor may be configured to search pre-specified areas (e. 
g.. local directories and/or remote servers), dynamically 
specified areas (e.g.. depending upon the program from 
which the interface is Invoked, the type of interface or 
an identity of a user) or all accessible areas. In partk:u- 
lar, the locator is designed to search across a network 
such as the Intemet. If suitable Information is found, It 
can be stored in the registry for easy location and re- 
trieval the next time it is needed. The procedure de- 
scribed above for creating a class loader and instantiat- 
ing an implementation is then perfomied. 
[0013] One embodiment of the invention thus pro- 
vides a method of constructing a self -organizing soft- 
ware environment in whk:h objects (e.g., interface im- 
plementations) are located and bound at the time a par- 
ticular service, function or behavior is required. If one 
object retrieved through this method requires further 
support (e.g., a service of another interface), another 
object may be located and attached to the environment 
when needed. Thus, functionality may be added to a 
particular program that was not envisioned when the 
program was developed. 

BRIEF DESCRIPTION OF THE FIGURES 



FIG. 4 is a btock diagram of a hierarchical context 
framework for facilitating the resolution of a request 
for an interface in accordance with an embodiment 
of the invention. 

DETAILED DESCRIPTION 



[0015] The folk>wing descriptk>n is presented to ena- 
ble any person skilled in the art to make and use the 
10 invention, and is provided In the context of partkxilar ap- 
plications of the invention and their requirements. In par- 
ticular, one skilled in the art will recognize that the 
present invention is not limited to the use of the Java^ 
programming language. The use of other object-orient- 
is ed programming languages are similarly envisioned. 
Thus, the present invention is not intended to be limited 
to the embodiments shown, but Is to be accorded the 
widest scope consistent with the principles and features 
disclosed herein. 
^0 [001 6J A program environment in which a present env 
bodiment of the invention is executed may incorporate 
a general-purpose computer or a special purpose de- 
vice such a hand-held computer. Details of such devk:es 
(e.g., processor, memory, data storage and display) are 
25 welt known and are omitted for the sake of clarity. It 
should also be understood that the techniques of the 
present invention might be implemented using a variety 
of technologies. For example, the methods described 
herein may be implemented in software running on a 
30 computer system, or Implemented in hardware utilizing 
either a combination of microprocessors or other spe- 
cially designed application specific integrated circuits, 
programmable logic devices, or various combinations 
thereof. In particular, methods described herein may be 
55 implemented by a series of computer-executable in- 
structions residing on or in a storage medium such as a 
cannier wave, disk drive, or other computer-readable me- 
dium. Exemplary fomns of carrier waves may take the 
form of electrical, electromagnetic or optical signals con- 
40 veying digital data streams along a local network or a 
publicly accessible network such as the Intemet. 
[0017] In a present embodiment of the invention a 
system and methods are provided for resolving a re- 
quest for, or invocation of, an interface (e.g., an appii- 
43 cation programming interface, or API) or an implemen- 
tation of an interiace. A program may request an imple- 
mentatk>n of an interface, for example, in order to ac^ 
cess a service or method offered or identified by the in- 
terface. In an object-oriented programming environment 
so such as Java^, an Interface may be viewed as a set of 
abstract base classes containing one or more services 
or methods that may be used by a program. Illustratively, 
an interface in the Java^** programming language does 
not, however, include service definitions (e.g., executa- 
55 ble code for performing the services). In the Java'^** pro- 
gramming language, the implementation of an interface 
provides the necessary code for performing the Inter- 
face's service(s). 



[0014] 

FIG. 1 Is a block diagram depicting a system for re- 
solving a request for an implementation of an inter- 
face in accordance with an embodiment of the 
present Invention. 

FIG. 2 is a flow chart demonstrating a method of 
resoh^ing a request for an implementation of an ir>- 
terface in accordance with an embodiment of the 
present invention. 

FIG. 3 is a flow chart demonstrating an alternative 
method of resoh^ing a request for an implementa- 
tion of an interface in accordance with an embodi- 
ment of the present invention. 
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LAN or WAN or a public network such as the internet, 
or other communication link. 

[0026] Also, the search process may comprise nrujlth 
pie steps. Locator 1 04 may. for example, first search for 
a package of code containing a suitable implementation 
of the interface. Once such a package is found, locator 
104 may then search the package of code for the suit- 
able implementation. 

[0027] If k)cator 1 04 is successful it passes the infor- 
mation it locates to resolver 106. which operates as de- 
scribed above. Locator 104 may, for example, find a 
principal concerning a class loader that can load a suit- 
able implementation, in which case resolver 106 then 
instantiates the dass loader and the interface innple- 
mentation, as necessary. 

[0028] Illustratively, a principal describes how to cre- 
ate the object (i.e., implementation) that is to be bound 
to a requesting program. Thus, a principal may contain 
information Identifying how to create a class loader, 
such as the location of program code to download and 
execute, instructions for extracting the class loader from 
the program code. etc. In particular, in a Java^^ pro- 
gramming environment a principal may be a URL (Uni- 
form Resource Locator) or other URI (Uniform Resource 
Identifier) of a piece of Java™ code, a JAR (Java^^ AR- 
chlve) file, instructions for creating a class loader (e.g., 
a script, a Java™ class, a set of rules), etc. A principal 
may also store the class name of an implementation 
(and/or its associated interface) that can be created 
once the principal's class loader is instantiated. Thus, 
by searching for the name of an implementation (which 
may be similar to its associated interface), an interface 
or interface service, a suitable principal for creating a 
class loader and instantiating the implementation can 
be found. 

[0029] If locator 1 04 cannot locate an implementation 
of the interface or a class loader capable of creating an 
instance of an implementation of the interface, it may 
attempt to satisfy the program request in an alternative 
manner. In one embodiment of the invention, locator 1 04 
may generate or compose an artif k:ial or "dummy" inrv 
plementation. Alternatively, locator 104 returns an ex- 
ception (e.g., an error message) to program code 100. 
[0030] One skilled in the art will appreciate that the 
division of labor among registry 1 02, locator 104 and re- 
soh/er 106 Is flexible and is not limited to the arrange- 
ment described above. In particular, FIG. 1 depicts just 
one system for locating a suitable implementatton of a 
requested interface and returning a reference to an in- 
stance of the implementation. In an alternative embod- 
iment of the invention, registry 102 may be configured 
to act prinnarily as a data repository to store infonmatlon 
aiding a search for an implementation of the requested 
interface. The functions of locating an implementation 
of an interface, whether registered or not, and resolving 
it to an instaru^e of a suitable implementation are then 
performed by one or more modules acting with varying 
degrees of similarity to locator 1 04 and^or resolver 1 06. 



[0031 ] Registry 1 02 may comprise data relating to alt 
interfaces that have been requested or invoked or, for 
example, some number of the most recently or most fre- 
quently requested interfaces. A portion of registry 102 
5 may, for example, comprise a repository (e.g.. a cache) 
having a relatively fast response time. Such a repository 
would t>e well suited to storing the most recently or fre- 
quently used interfaces. 

[0032] In addition, after locator 104 locates informa- 
10 tion for an Implementation not known to registry 1 02, in- 
formation concerning the implementation or its class 
loader may be stored in registry 1 02 for easier retrieval 
the next time the same interface is requested. 
[0033] In different embodiments of the invention the 
15 operation and management of registry 1 02, kx^tor 104 
and resolver 1 06 may be performed by different entities. 
In partk:ular, in one embodiment of the invention a 
Java^^ Virtual Machine operates and manages one or 
more of these modules on behalf of one or rhore appll- 
20 cation programs comprising program code 100. In an 
alternative embodiment, however, an application pro- 
gram comprising 100 may incorporate the ability to 
maintain and operate registry 1 02, locator 1 04 and re- 
soh/er 1 06. 

25 [0034] One skilled in the art will appreciate that within 
a given programming environment, numerous methods 
of locating or creating a suitable implementation of a 
particular interface or interface service may be con- 
structed. Likewise, many methods of resolving impte- 
30 mentations with requested interfaces, and registering or 
tracking such resolutions may be designed. 
[0035] Operation of the system depicted in FIG. 1 may 
be recursive in that an implementation that is located 
and bound in response to the invocation of an interface 
35 or service by program code 100 may, in turn, request 
another interface or interface service. In particular, a tirst 
implementation that is resoh/ed by resolver 106 may 
specify a number of interfaces or interface services that 
it requires. The procedure described above is thus per- 
^ fomied again to locate and resolve other implementa- 
tions as needed. Thus, a sort of self-organizing software 
environment may be constructed in whbh interface im- 
plementations are k>cated and "attached" to the envi- 
ronment when an interface is invoked or requested. As 
4^ a result, program code 100 may gain the ability to per- 
form tasks not envisioned by its developer 
[0036] U.S. Patent No. 6,727.147 (the '147 patent), 
issued March 10, 1998 and entitied "System and Meth- 
od for Resolving Symbolfc References to Externally Lo- 
50 Gated Program Files" addresses the creation of applica- 
tion-specifk: class loaders. In the '147 patent an appli- 
cation-specify dass loader or an object class instanti- 
ated by an application-specific class loader may be lo- 
cated on a remote computer. The location of the remote 
55 object (s) however, are known beforehand. Thus, the 
'147 patent does not describe a search procedure such 
as described above for the embodiment of the present 
invention depicted in FIG. 1 . In addition, the '147 patent 
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(e.g.. the default set of locations to be searched for a 
Java^** class, object or set of code), the classpath of the 
dass loader associated with the requested interface, a 
remote server or system that hosts the requesting pro- 
gram, a central server, a library server, a network search 
utility (e.g.. Yahoo, Excite), an Intemetsite. etc. 
[0047] If in state 21 0 the search for a dass loader or 
prindpal is unsuccessful, an exception (e.g.. an error 
message) is returned to the requesting program in state 
212. In an alternative embodiment of the Invention, the 
system perfonning the illustrated method may attempt 
to determine some other manner of performing a re- 
quested service for which no implementation can be lo- 
cated, unless the sen/ice Is part of a critical operation of 
the requesting program. The Illustrated method then 
ends with end state 220. 

[0048] If, however an entry was found in the registry 
for the requested Interface (state 206). or a class loader 
or principal was found pursuant to a search (state 21 0), 
the illustrated method proceeds to state 214. In state 
214 a reference to a suitable class loader is retrieved 
(e.g., from the registry) or a class loader associated with 
an implementation of the interface is created (e.g., in- 
stantiated) from the available infomiation. 
[0049] In state 21 6 an instance of the implementation 
is retrieved, If it exists, or the class loader is called upon 
to instantiate the Implementation class. In one embodi- 
ment of the invention, if an interface is found to be reg- 
istered in state 206 the illustrated method may proceed 
directly to state 21 6 from state 206. This may occur, for 
example, if the registry directly identifies an existing in- 
stance of the implemenlatbn. 

[0050] In state 218, the implementation is invoked in 
place of the interiace invocation received in state 202. 
After state 218 the method ends with end state 220. 
[0051] FIG. 3 depicts one alternative method of satis- 
fying a program's request for an interface. In this method 
the program framework itself incorp)orates the ability to 
locate a suitable implementation of the requested inter- 
face. As one skilled in the art will recognize, the portion 
of the program that perfomis the illustrated method may 
require certain privileges in order to perform the identi- 
fied tasks. State 300 is a start state. 
[0052] In state 302. a component (e.g., object) of an 
application program requires an interface or Interface 
service. The component may invoke the interface or 
service during its execution or the application framework 
may identify the need for the interface before the corrv 
ponent makes the invocation. The application frame- 
woricmay, for example, identify the needforthe interface 
when the program component is instantiated. 
[0053] In state 304 a registry is searched, illustratively 
using the requested interface as a key or index. As in 
the method of FIG. 2, for each interface registered In the 
registry a dass loader that can install or create an im- 
plementation of the interface may be identified. The reg- 
istry may store a reference to a dass loader instance or. 
alternatively, identify infomnation from whfch a dass 



loader capable of creating an implementation of the in- 
terface may be created (e.g., a principal). 
[0054] If. in state 306. no entry is found in the registry 
for the requested interface, in state 308 a search is con- 
5 ducted for a dass loader of an implementation of the 
interface and/or a principal from which such a class 
loader may be created. 

[0055] If in state 31 0 the search for a class loader or 
prindpal Is unsuccessful, an exception (e.g., an error 
10 message) is returned to the requesting program in state 
312. In an alternative embodiment of the invention the 
application framework may attempt to detemnine some 
other manner of performing a requested sen^ice for 
which no implementation can be located, unless the 
IS service Is part of a critical operation of the program. The 
illustrated method then ends with end state 320. 
[0056] If, however, an entry was found In the registry 
for the requested Interface (state 306), or a dass loader 
or principal was found pursuant to a search (state 31 0), 
^ the illustrated method proceeds to state 314. In state 
314 a reference to a suitable class loader is retrieved 
(e.g., from the registry) or a class loader associated with 
an implementation of the interface is created (e.g., In- 
stantiated) from the available information. 
25 [0057] In state 31 6 an instance of the implementation 
is retrieved, if it exists, or the class loader is called upon 
to instantiate the implementation class. In one embodi- 
ment of the invention, if an interface is found to be reg- 
istered in state 306 the Illustrated method may proceed 
30 directly to state 31 6 from state 306. 

[0058] In state 318, a reference to an instance of the 
implementation Is retumed to the program. After state 
31 8 the method ends with end state 320. The program 
may invoke the implementation as part of end state 320. 
35 [0059] In one alternative embodiment of the invention, 
a registry contains information concerning implementa- 
tions of interfaces in addition to or in place of class toad- 
er and/or principal information. The registry may, for ex- 
ample, comprise multiple data structures or repositories 
40 (e.g., databases, tables, arrays, flat files, lists). A first 
portion of a registry may comprise a relatively fast data 
structure (e.g.. an object table, a hardware or software 
cache) consisting of entries mapping interfaces to class- 
es of implementations of the interface or instances of 
^ such implementations. Entries included In this first por- 
tion may be limited to the most recently or most frequent- 
ly used interfaces. 

[0060] When an implementation class for a requested 
interface is identified in this first portion of a registry, the 
^ Implementation is instantiated (e.g., by resolver 106 of 
FIG. 1). instead of identifying an implementation dass, 
however, the registry may identify a reference to an ex- 
isting Instance of the implementation. The implementa- 
tion is then retumed to the requesting program (e.g., by 
S5 retuming a reference to a new or existing instar>ce) or 
is invoked in place of the interface invocation. If there is 
no entry for a requested interface in a first portion of the 
registry in this alternative embocfiment. a second portion 
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within the framework (e.g.. at a low level number) may 
export its services to services lower in the framework (e. 
g.. at a higher-numbered level) by storing appropriate 
information in the contexts associated with the lower 
services. Thus, when an object or applk:ation in context 
442 requires a particular se^rvice, the registry for context 
442 may contain a reference to a definition of the service 
(e.g., an instance of an implementation of the service's 
interface) in context 420, for example. This avoids hav- 
ing to pass the request through the framework to context 
430 and then context 420. 

[0073] As specified above, within a framework of con- 
texts for resolving requests for interfaces or interface 
services each context may maintain its own registry. 
Thus, users connected to different contexts may have 
their requests for the same interface satisfied by differ- 
ent implementations of that interface. This may be IHus- 
iraied by revisiting the adventure game example de- 
scribed above. One set of players (e.g., adults) may be 
Hssocialed with a context in which Monster objects are 
imbued with menacing attributes. A Dinosaur Monster, 
for example, may be an enormous carnivore intent on 
devouring a player's character Another set of players 
(c g children) may be associated with a context in 
which Monster objects are more innocuous. A Dinosaur 
MDnslcr in this context, for example, may be purple and 
sport a smarmy fa9ade (but still exhtoit noisome activity 
RiiCh as singing). 

[0074] Thus, the context with which a user is associ- 
rtiod may define the behavior of a program operated by 
ine u5or The context's registry may be maintained by a 
portion of an application framework associated with the 
ccnicxi by a JVM or by some other entity with suitable 
privileges or access to locations at which interface im- 
plcmcnialions may be stored. Through its registry, a 
ccntcxi may inform an application program framework 
or JVM where to look for certain objects, how to find a 
dcfin:iion for an interface service, what objects should 
be connected to a user's program, etc. 
[0075] Each contexts registry may be created when 
the conroxi is spawned or when a first user is placed in 
ihc conioxt. Further, each contexts registry may be in- 
itiali/od oy copying the registry of its parent. By copying 
registries, the export of services from more general to 
more specific contexts is simplified. Within a context, 
however its registry is updated as interfaces are re- 
quested and implementations of the requested interfac- 
es are located and resolved. 

[0076] The foregoing descriptions of embodiments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to.be 
exhaustive or to limit the invention to the forms dis- 
closed. Many modifk:ations and variations will be appar- 
ent to practitioners skilled in the art. Accordingly, the 
above disclosure is not intended to limit the invention; 
the scope of the invention is defined by the appended 
claims. 

[0077] In particular, in one or more of the embodt- 
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ments of the invention described above, a registry may 
be supplemented over time as requests for interfaces 
are satisfied. For example, as descrft>ed in conjunctk>n 
with the method illustrated in FIG. 2. a search is made 
for a class loaderor principal when a requested interface 
is unknown to the registry. If such a search is successful, 
an entry is ntade in the registry so that a subsequent 
request for the same interface may be satisfied without 
the delay that is inherent in having to conduct a search. 

Claims 

1. A method of resoh^ing a first reference to a first in- 
terface service issued by a program executing on a 
computer, the method comprising: 

receiving (202) a first reference to a first Inter- 
face service from a program executing on a 
computer; 

searching (204) for a program object class that 
is configured to define said first interface sen^- 
ice; 

identifying (21 6) a first program object class un- 
known to said program at the time said first ref- 
erence is received; 

if an instance of said first object class is una- 
vailable, creating (216) an instance of said first 
object class; and 

resolving (218) said first reference with said In- 
stance of said first object class. 

2. The method of claim 1 , further comprising Identify- 
ing (214) a class loader configured to instantiate 
said first object class. 

3. The method of claim 1, wherein said searching 
(204) comprises determining whether an object 
class configured to define said first service is kJen- 
tified in a first memory of the computer 

4. The method of claim 1, wherein said searching 
(204) comprises searching across a publicly acces- 
sible networic for an object class configured to de- 
fine said first interne service. 

The method of claim 1 , wherein said resolving (21 8) 
comprises binding said iristance of said first object 
class to said program. 

The method of claim 1 , further comprising detemnin- 
ing whether saki instance of said first object class 
Invokes a second interface service unknown at the 
time the program was loaded. 



5. 



The method of claim 
(204) comprises: 



1, wherein said searching 
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terface service. 

19. The method of claim 17, further comprising: 

receiving a second reference to a second inter- 
face service during execution of said instance 
of said first implementation of said first interface 
service; 

discovering (308) a class loader configured to 
instantiate an implementation of said second 
interface service; 

resolving (31 8) said second reference by load- 
ing an instance of said implementation of said 
second interface service; and 
adding to said first memory information con- 
ceming said implementation of said second in- 
terface service. 

20. The method of claim 1 7, wherein said discovering 
(314) comprises searching one or more electronic 
storage areas for an implementation of said first in- 
fonmation service that is not already identified in 
said first memory. 

21. The method of claim 20, wherein one of said one or 
mora electronic storage areas is remote from the 
computer. 

22. The method of claim 20. wherein said discovering 
further comprises: 

locating said first implementation of said first in- 
terface service: and 

instantiating (316) said first Implementation of 
said first interface sen^ice. 

23. The method of claim 20, wherein said discovering 
further comprises: 

If said searching for an Implementation of said 
first interface service is unsuccessful, search- 
ing (308) for means of facilitating the creation 
of an implementation of said first Interface serv- 
ice not already identified in said first memory. 

24. The method of claim 23, wherein said means is a 
class loader. 



25.* The method of claim 23, wherein said discovering 
further comprises: so 

if said searching for means of creating an irrv 
plementatlon of said first interface service is un- 
successful, searching for means of facilitating 
the creation of a cla^ loader configured to load 55 
an implementation of said first interface service 
that is not already identified in said first memo- 
ry. 
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26. The method of claim 25, wherein said means is a 
Unifonm Resource Identifier, a Java Archive file, or 
a series of computer-executable instructions for 
creating a class loader 

27. A computer system comprising: 

a processor configured to execute a program 
(1 00), wherein during said execution of the pro- 
gram a first reference is made to a first interface 
service, and wherein said reference must be re- 
solved in order to continue said execution; 
a registry (1 02) configured to identify means for 
resolving references to interface services made 
during execution of the program; 
a locator (104) configured to search said regis- 
try for means of resoh^lng said first reference; 
and 

a resolver (1 06) configured to access a first im- 
plementation of said first interface servkre and 
resolve said first reference with an instance of 
said first implementation. 

28. The computer system of claim 27, wherein said first 
implementation was unknown at the time the pro- 
gram was loaded for execution by said processor. 
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29. The computer system of claim 27, wherein said lo- 
cator (104) is further configured to search one or 
30 more electronic storage areas other than said reg- 
istry for means of resolving said first reference. 



30. The computer system of claim 27, wherein said lo- 
cator (104) Is further configured to search one or 
more electronic storage areas remote to the com- 
puter system for means of resolving said first refer- 
ence. 

The computer system of claim 27, wherein said reg- 
istry (102) comprises a memory configured to store 
an identifier of a known implementation of an inter- 
face service. 

32. The computer system of claim 27, wherein said reg- 
istry (102) comprises a memory configured to store 
an Identifier of a class loader with which an imple- 
mentation of an interface servk^e may be created. 

33. The computer system of claim 27, wherein said reg- 
istry (102) includes a hierarchrcal set (400) of con- 
texts, said hierarchical set of contexts comprising: 

a first context (41 0), comprising a first definitk>n 
of an interface service; and 
a second context (420), comprising a second 
definition of another interface servk^e; 

wherein said second context is searched for 
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11. Verfahren nach Anspnich 10, bei dem der Versuch 
(208) einer Lokalisierung umfaBt: 

Siichen eines Oder mehrerer Kontexte in einer 
hierarchischen Menge (400) von Kontexten, 
wobei jederKontext in der Menge von Kontex- 
ten so konfiguriert ist, daB er eine Bezugnahme 
auf einen Schnittstellendienst fur eine den 
Dienst definterende Implementierung auftdst; 
und 

falls die erste Bezugnahme in einem ersten 
Kontext (420) in der hierarchischen Menge von 
Kontexten nicht auf gelost werden kann, Versu- 
chen, die erste Bezugnahme in einem zweiten 
Kontext (41 0) in der hierarchischen Menge von 
Kontexten aufzuldsen. 



12. 



13. 



14. 



Verfahren nach Anspruch 1 , bei dem das Auf Idsen 
(218) die Ruckfuhrung (318) einer Bezugnahme auf 
die Instanz der ersten Objektklasse zum Programm ^ 
umfaBt. 

Verfahren nach Anspruch 1 , bei dem das Auf losen 
(21 8) das Aufruf en (21 8) der Instanz der ersten Ob- 
jektklasse umfaBt. ' 25 

Verfahren nach Anspruch 1 , bei dem das Suchen 
(204) das Durchsuchen eines ersten Speichers 
nach einer Implementierung des ersten Schnittstel- 
lendienstes umfaBt. wobei der erste Speicher in 30 
dem Computer vorhanden ist. 

Verfahren nach Anspruch 14, bei dem das Suchen 
(204) ferner das Suchen eines entfernten Compu- 
tersystems, das mit dem Computer elektrisch ge- 35 
koppett ist, umfaBt. 

Verfahren nach Anspruch 1, bei dem das Suchen 
(204) das Identifizieren (214) eines Klassenladers, 
der einer Implementierung des ersten Schnittstel- <o 
lendienstes zugeordnet ist, umfaBt. 



17. Verfahren zum Erweitern einer dynamischen 
Sammlung von Infonnationen. urn eine Schnittstel- 
lendlenst-Bezugnahme von einem Programm fOr 
eine Implementierung des Schnittstellendienstes, 
auf den Bezug genommen wird, aufzuldsen, wobei 
die dynamische Sammlung von Informationen so 
konfiguriert ist, daB sie Informationen enthdit, die 
Implementierungen betreffen, die zu dem Zeit- so 
punkt, zu dem das Programm geladen wird, be- 
kannt Oder unbekannt sind, wobei das Verfahren 
umfaBt: 

Laden eines Programms in einen Computer, 55 
wobei wahrend des Ladens eine oder mehrere 
bekannte Implementierungen von Schnittstel- 
lendtensten, auf die durch das Progranrun Be- 



15. 



16. 



zug genommen werden kann. in einem ersten 
Speicher identifiziert werden; 
Empfangen (302) einer ersten Bezugnahme 
auf einen ersten Schnittstellendienst wahrend 

5 der Ausfuhrung des Programms: 

FInden (31 4) einer ersten Implementierung des 
ersten Schnittstellendienstes, wobei cfie erste 
Implementierung in dem ersten Speicher nicht 
identifiziert wird; 

10 1-linzufugen von Informationen. die die erste Im- 

plementierung des ersten Schnittstellendien- 
stes betreffen, zu dem ersten Speicher; und 
Aufldsen (31 8) der ersten Bezugnahme durch 
Binden einer Instanz der ersten Implementie- 

15 rung des ersten Schntttstellendienstes. 

18. Verfahren nach Anspruch 17. das femer umfaBt: 

Empfangen einer zweiten Bezugnahme auf ei- 
nen zweiten Schnittstellendienst wahrend der 
Ausfuhrung der Instanz der ersten Implemen- 
tierung des ersten Schnittsteilendiensts; 
Finden (314) einer Implementierung des zwei- 
ten Schnittsteliendiensts, die in dem ersten 
Spek^her nicht identifiziert wird; 
Aufldsen (31 8) der zweiten Bezugnahme durch 
Binden einer Instanz der implementierung des 
zweiten Schnittsteliendiensts; und 
Hinzufugen von Informationen, die die Imple- 
mentierung des zweiten Schnittsteliendiensts 
betreffen, zu dem ersten Speicher. 

19. Verfahren nach Anspruch 17, das ferner umfaBt: 

Empfangen einer zweiten Bezugnahme auf ei- 
. nen zweiten Schnittstellendienst wahrend der 
Ausfuhrung der Instanz der ersten Implemen- 
tierung des ersten Schnittsteliendiensts; 
Finden (308) eines Klassenladers, der so kon- 
figuriert ist, daB er eine Implementierung des 
zweiten Schnittsteliendiensts instanzilert; 
Aufldsen (31 8} der zweiten Bezugnahme durch 
Laden einer Instanz der Implementierung des 
zweiten Schnittsteliendiensts; und 
HlnzufOgen von Informationen, die die Imple- 
mentierung des zweiten Schnittsteliendiensts 
betreffen, zum ersten Speicher. 

20. Verfahren nach Anspruch 17, bei dem das Entdek- 
ken (314) das Durchsuchen eines Oder mehrerer 
elektronischer Speicherberek:he nach einer Imple- 
mentierung des ersten Informationsdiensts, der 
nicht bereits in dem ersten Spek^her identifiziert 
worden ist, umfaBt. 

21. Verfahren nach Anspruch 20, bei dem einer der 
mehreren elektronischen Spek:herbereiche sch 
entf emt von dem Computer bef indet. 
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terprogramms unbekannt war, nach einem der An- 
sprOche 1 bis 1 6 Oder einem der Anspruche 1 7 bis 
26 auseufuhren. 

35. Computerprogranvn nach Anspruch 34, das als ein 
connputerlesbares Speichenmedlum ausgefuhrt ist. 

Revendications 



7. 



1. 



5. 



6. 



Proc6d6 pour resoudre une premiere reference a 
un premier service ^interface envoyee par un pro- 
gramme s'exteutant sur un ordinateur, te proc^d6 
comportant les etapes consistant k : 

recevoir (202) une premifere r6t6rence a un pre- 
mier service d'interface provenant tfun pro- 
gramme s'ex6cutant sur un ordinateur, 
rechercher (204) une classe d'objet de pro- 
gramme qui est configur6e pour d^finir ledit 
premier service ^Interface, 
identifier (216) une premiere classe d'objet de 
programme inconnue dudit programme au mo- 
ment ou ladite premiere rdf^rence est re9ue, 
si une instance de ladite premiere classe d'ob- 
jet n'est pas disponible, creer (21 6) une instan- 
ce de ladite premiere ciasse d'objet, et 
r6soudre (218) ladite premiere r6f6rence k 
Taide de ladite instance de ladite premiere das- 
se d'objet. 



10 



IS 8. 



20 



25 



9. 



30 



Proced6 selon la revendication 1, comportant en 
outre I'Identification (214) d'un chargeur de classe 
configure pour instancier ladite premiere classe 
d'objet. 35 

Precede selon la revendication 1 , dans lequei ladite 
recherche (204) comporte la d6temiination du fait 
qu'une classe d'objet configur^e pour d^finir ledit 
premier service est identifi^e dans une premiere 40 
memoire de Pordinateur. 

Proc6d6 selon la revendication 1 . dans lequei ladite 
recherche (204) comporte la recherche d iravers un 
r6seau accessible publiquement d'une classe d'ob- 43 
jet configur6e pour d6finir ledit premier service d'in- 
terface. 



10, 



Proc^dd selon la revendication 1 , dans lequei ladite 
resolution (218) comporte l'6dftk>n de lien de ladite 
instance de ladite premiere classe d'objet audit pro- 
gramme. 



so 



11. 



Proc6d6 selon la revendication 1 , comportant en 
outre r^tape consistant k determiner si ladite ins- 55 
tance de ladite premiere classe d'objet appelle un 
second service d'interface inconnu au moment ou 
le programme a charge. 



Precede selon la revendication 1 , dans lequei ladite 
recherche (204) comporte les etapes consistant k : 

cheicher un ou plusieurs contextes dans un en- 
semble hierarchique (400) de contextes. ou 
chaque contexte dudit ensemble de contextes 
est configure pour resoudre une reference k un 
service d'interface relatif k un objet configure 
pour definir le service d'interface, et 
tenter de resoudre ladite premiere reference 
dans un second contexte (41 0) si ladite premie- 
re reference ne peut dtre resolue dans un pre- 
mier contexte (420). 

Precede selon ia revendication 1, comportant en 
outre les etapes consistant a : 

recevoir une seconde reference k un second 
service d'interface pendant ladite resolution de 
ladite premidre reference, oCi ledit second ser- 
vice d'interface etait inconnu avant ladite reso- 
lution, et 

acceder k une instance d'une premiere imple- 
mentation dudit second service d'interface. 

Precede selon la revendication 8, comportant en 
outre un enregistrement de ladite premiere instance 
de ladite premiere classe d'objet et de ladite pre- 
miere implementation dudit second service d'inter- 
face dans une structure de donnees configuree 
pour faciliter la resolution de references de pro- 
gramme. 

Precede selon la revendication 1 , dans lequei ladite 
recherche (204) comporte les etapes consistant k : 

tenter de localiser une Implementation de ladite 
premiere classe d'objet de programme, 
si ladite tentative pour localiser une implemen- 
tation de ladite premiere classe d'objet de pro- 
gramme echoue, tenter (208) de localiser un 
chargeur de classe configure pour creer une 
implementation de ladite premiere classe d'ob- 
jet de programme, et 

si ladite tentative pour localiser un chargeur de 
classe echoue, tenter (208) de localiser des 
moyens pour creer un chargeur de classe con- 
figure pourcreerune implementation de ladite 
premiere classe d'objet de programme. 

Precede selon la revendication 10, dans lequei la- 
dite tentative (208) de localisation comporte les eta- 
pes consistant k : 

chercher un ou plusieurs contextes dans un en- 
semble hierarchique (400) de contextes, ou 
chaque contexte dudit ensemble de contextes 
est configure pour resoudre une reference k un 
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premier service cfinterface, et 

instancier(31 6) ladite premiere impl^entation 

dudrt premier service d'interface. 

23. Proc6d6 selon la revendication 20, dans lequel la- 
dite decouverte comporte en outre Petape consis- 
tant k : 

si ladite recherche d'une implementation dudit 
premier service tfinterface echoue. rechercher 
(308) des moyens pour facfliter la creation 
d*une impl^entation dudit premier service 
d'interface non ddj^ identifite dans ladite pre- 
miere m^oire. 

24. Proced6 selon la revendication 23, dans iequel les- 
dits moyens sent un chargeur de classe. 



29. 



10 



dans lequel ladite premiere Implementation 6tait in- 
connue au moment oil te programme a et6 charge 
pour etre execute par ledit processeur. 

Systeme infonmatlque selon la revendication 27. 
dans lequel ledit localisateur (1 04) est en outre con- 
figure pour rechercher dans une ou plusieurs zones 
de memorisation eiectroniques autres que ledit re- 
gistre des moyens de resolution de ladite premiere 
reference. 



30. Systeme infomnatique selon la revendication 27, 
dans lequel ledit localisateur (1 04) est en outre con- 
figure pour rechercher dans une ou plusieurs zones 
*5 de memorisation electron iques distantes du syste- 
me Informatique des moyens de resolution de ladite 
premiere reference. 



25. Procede selon la revendication 23, dans lequel la- 
dite decouverte comporte en outre i'etape consls- 
tant d : 

si ladite recherche de moyens de creation 
d*une implementation dudit premier service 
d'interface echoue, rechercher des moyens 
pour faciliter la creation d'un chargeur de clas- 
se configure pour charger une implementation 
dudit premier service d'interface qui n'est pas 
dejd identifiee dans ladite premiere memoire. 

26. Precede selon la revendication 25, dans lequel les- 
■ dits moyens sont un Identificateur de Ressource 

Uniforme, un fichier d'Archives Java, ou une serie 
d'instructions executables par ordinateur destines 
d creer un chargeur de classe. 



31 
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Systeme informatique selon la revendication 27. 
dans lequel ledit registre (102) comporte une me- 
moire configuree pour memoriser un identificateur 
d'une Implementation connue d'un service d'inter- 
face. 



^5 32. Systeme infonmatique selon la revendication 27, 
dans iequel ledit registre (102) comporte une me- 
moire configuree pour memoriser un identificateur 
d'un chargeur de classe a I'aide duquel une imple- 
mentation d'un service tfinterface peut etre creee. 



30 



35 



27. Systeme infomnatique comportant : 

un processeur configure pour executor un pro- 
gramme (100), ou pendant ladite execution du 40 
programme^ une premiere reference est effec- 
tuee k un premier service d'interface, et oD la- 
dite reference dolt etre resolue afin de conti- 
nuer ladite execution, 

un registre (102) configure pour Identifier des 45 
moyens destines k resoudre des references k 
des services d'interface effectues pendant 
I'execution du programme, 
un localisateur (1 04) configure pour rechercher 
dans ledit registre des moyens destines e r6- so 
soudre ladite premiere reference, et 
un dispositif de resolution (106) confrgur6 pour 
acceder k une premiere implementation dudit 
premier service d'interface et resoudre ladite 
premiere reference e I'aide d'une instance de 55 
ladite premiere Implementation. 

28. Systeme informatique selon la revendication 27, 



33. Systeme informatique selon la revendication 27, 
dans lequel ledit registre (102) inclut un ensemble 
hierarchlque (400) de contextes, ledit ensemble 
hierarchlque de contextes comportant : 

un premier contexte (41 0), comportant une pre- 
miere definition d'un service d'interface, et 
un second contexte (420), comportant une se- 
conde definition d'un autre service d'interface, 

dans lequel ledit second contexte fait t'objet 
d'une recherche d'une definition dudit premier ser- 
vice d'interface et, si ledit second contexte ne con- 
lient pas ladite definition, ledit premier contexte est 
recherche. 

34. Programme informatique qui. lorsqu'il est execute 
par un ordinateur, amdne I'ordinateur k executor un 
precede pour resoudre une reference provenant 
tf un programme Informatique k un service d'inter- 
face k I'aide d'une implementation de I'interface qui 
etait inconnue pendant le chargement du program- 
me informatique, selon I'unequelconquedes reven- 
dications 1 4 16, ou des revendications 17 e 26. 

35. Programme informatique selon la revendication 34. 
mis en oeuvre sur un support de nrtemorisation lisi- 
ble par ordinateur. 
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